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Remarks 



Claims 1-29 are pending in the app 



Ication. All claims stand rejected. By this 



paper, claim 1 has been amended. New claims 30 and 31 have been added to 
provide claim coverage commensurate! with the scope of the invention. 



Reconsideration of all pending claims herein is respectfully requested. 

Claims 1, 8, 12, and 29 were rejected under 35 U.S.C. 102(e) as being 

anticipated by U.S. Patent No. 6,269,078 to Lakshman et al. ("Laksham"). Claims 2- 

|l 

7, 9-11, 13-17, and 27-28 were rejected under 35 U.S.C. 103(a) as being 

Ji 

il 

unpatentable over Lakshman in view of Ito et al. flto"). Claims 18, 21-22, and 26 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Lakshman in vie of 
Humpleman. Claims 19-20 arid 23-25 Were rejected under 35 U.S.C. 103(a) as 

j; 

being unpatentable over Lakshman et al in view of Humpleman and further in view of 

|; 

Ito. These rejections are respectfully traversed. 

|i 

The pending application allows a media server to anticipate a future bitrate 

i| 

spike in a previously-encoded multimedia! program to be sent to a receiving node, 



and to proactively adjust the bandwidth al 
spike without interruption. By retrieving a 



bcated to the receiving node to handle the 

i 

[previously-generated bitrate histogram for 



1 1 

the previousfv-encoded multimedia program, the server is aware of the spike well 

ji 

before it occurs, and may take steps tot prevent a buffer underrun, such as by 

I * 

providing additional bandwidth to fill the receiving node's buffer. 

li 

Lakshman relates to an entirely different "adaptive" encoding process based 
on bitrate prediction for video to be encolded in the future . The encoder predicts 

|! 

(501) the need for rate allocation for future frames and provides (502) the predicated 

i: 



1Qj 

i; 
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rate to a network. The network allocates (604) bandwidth in response to the request 

i 

and advises (504) the source of an explicit rate based on the actual available 
bandwidth- The encoder at the source then adjusts (505) the current rate based on 
the advised explicit rate. See FIG. 5. ! 

By contrast, the claimed invention cloes not predict the bitrate. It conclusively 
knows the required bitrate at any point during the transmission based on the 
previously-generated bitrate histogram jfor the previously-encoded multimedia 

program. Moreover, the claimed invention does not adjust the encoding rate based 

i 

feedback from the network. Indeed, the content has already been encoded and does 

not need to be re-encoded. (Note that while claim 1 has been amended to explicitly 

.i 

recite that the media program was "previously encoded," this limitation was already 

I 

included in independent claims 8, 18, 27, and 29). 

Lakshman needs to predict the bitrate and adjust the encoding because 

i 

Lakshman relates to video that has not yet been encoded, such as in a video 



conference. CoL 9, lines 64-67. Lakshman uses a "mechanism for predicting 

■ ■ i 

demands to be made of the network based on the character of the video information 



which is to be encoded in the' future" ,Col. 5, lines 2-4 (emphasis added). The 
encoder cannot know in advance what the bitrate will be at any given time, since the 

! ! 

video has not yet been captured, let alone encoded. Accordingly, it can only look at 

the character or type of video tp be sent! making the goals and overall mechanism 

, i 

r 

employed by Lakshman completely different from that of the claimed invention. 



Turning to the claim recitations, 



claim 1 recrtes identifying a previously- 



generated histogram of bitrate; as a function of time associated with previously- 



1| 
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encoded multimedia program, jFig. 6A of Laksham illustrates a histogram of the 
frequency of B frames in a studied sequence. "B frames are shown because they are 

the most frequently occurring frames in thje studied sequence." Column 9, lines 48- 

* i 

50. Fig. 6A is not a bitrate histogram. A bitrate histogram illustrates a bitrate, i.e. 

i ! 
j i 

kBKs/sec, over a period of time. This is supported by Figures 9a and 9e-m and 

i * j 

accompanying text. Laksham discloses frequency of B frames versus cells per frame 

and not a bitrate over time. Fig. 6A purposefully omits I and P frames so that a 

i i 

1 ' I 

bitrate for the studied sequence is impossible to calculate. Determining the bitrate 

» i 

requires substantially more data; which is [not presented in the graph of Fig. 6A. Fig. 

i 

6A discloses the frequency ofj B frames which is relevant for the discussion of 

' : I 

correlation that follows. Fig. 6A cannot reasonably be interpreted as a bitrate 

! i 

histogram for a multimedia content. | 

; " ! 

Furthermore, the graph 'pf FIG. 0A cannot be a histogram of bitrate as a 

function of time, which could beiused to anticipate upcoming bitrate spikes, because 

1 : f 

there is not time axis. For; example, the graph shows approximately 1000 



occurrences of 100 cells per frarr^e, with 



a much smaller number of occurrences of 



250-300 cells per frame. However, this graph tells nothing about the temporal 

position within the media program at which the 250-300 cells per frame occur. The 

i : j 

graph cannot be used to anticipate bitrate-jspikes. 

1 : t 

! A 

Lakshman does not disclose or suggest a histogram of bitrate as a function of 
time "associated with a previodslv-encoded media program to be transmitted to a 

; ! 

multimedia node." Lakshman's histogram in FIG. 6A is a histogram of cell rates for a 

i ! 

particular type of multimedia content (e.g.. video conferencing), not a particular media 



! . 12 
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f 

t \ 

I : 

! 

program to be sent to a receiving node, as claimed. In other words, FIG. 6A is used 

i i 

to model the characteristics- of a type of multimedia content, not to map a specific 
media program's content As 'explained by Lakshman, w [h]aving considered the 

active and inactive sources and jth'eir characteristics , it is possible to thus model and 

: i 

predict what the cell rate needs will be for the encoder based on the types of video to 
be transmitted." Lakshman sumply does not disclose or suggest a previously- 
generated bitrate histogram for ^he media program to be transmitted . It is a generic 

histogram of cell rates vs. frequency for categories of multimedia. 

I ; 

Claim 1 further recites changing a bandwidth allocation for the multimedia 

i 

i , 

node in anticipation of a future bitrate spike indicated in the bitrate histogram. Fig. 6A 

i . 

is "helpful for understanding the prediction of demand rates in accordance with the 
present invention." Column 4, links 41-43. However, Fig. 6A does not indicated a 

I r 

bitrate spike. Laksham disclosejs Jthe prediction or forecasting of rates and does not 

rely on a bitrate histogram to indicate a known spike. "In an embodiment of the 

i ; , 

present invention the encoder predicts needed rates over very short intervals and 

i ■ 

requests a rate of the network! using a resource management cell provided in the 

i i 

ABR service scheme." Column 3,ilmes 59-62 (emphasis added). 

With respect to Figs; 6A sjntf 6B, Laksham states that 

: ! i 

Also from the plot of auto-correlation it is clear that the short-term correlations 
are very high - a fact to be exjplorted in forecasting. The forecasting can be 
done using the source model developed in the Heyman article. 

Column 9, lines 58-61 (emphasis added). Laksham relies on forecasting and 

prediction that are done by models. "In connection with describing a technique for 

predicting the needs of the source in terms of bandwidth allocation, the inventors 



13 
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L 

; ■ | 

: " I ". j 
have focused on models which characterize the videb input in terms of the number of 

i 

: .! I 

cells per frame of video." Column! 7, lines 31-35 (emphasis added). Laksham then 
proceeds to disclose various models for predicting cell rate needs including the 

■ '. ! 

Discrete Auto-regressive : model (column 8, lines 6-38), the Gamma-Beta 

* : 
' i. 

Autoregressive model (column 8, line 39 to column 9, line 29), an* the Active Source 
Model (column 9, line 30 «to column 10, line 16),! as well as "Source Models of 
Broadcast-Video Traffic", Heymanf et al (column 8, llines 26-28 and column 9, lines 

' ! 
I 

60-61 ). All of these models: and the entire disclosure of Laksham relates to predicting 
demands. Laksham has no teachmg or suggestion pf relying on the histogram of 6A, 

■ ! 

■ i ; 

or any other histogram, that indicates a bitrate spike. Laksham relies entirely on 

f , ! 

forecast models rather than a histogram that tracks a previously-generated bitrate. 

i i i 

In the pending application, i a media server qroactively adjusts the bandwidth 

allocated in anticipation of a future bitrate spike. By {anticipating upcoming bandwidth 

I j ; 
spikes using the bandwidth histogram, a system may take proactive measures to 

i i i 
increase bandwidth to a particular Multimedia node tp ensure that the node's buffer is 

full when the spike arrives. Laksham has noi such teaching or suggestion. 

I |: • i 

Accordingly, Laksham do§s not change a bandwidth allocation in anticipation of a 

i . | ; 
future bitrate spike indicated in 'a bitrate histogram. Rather, Laksham predicts 

• : I 

' .i 

demands to a network and calculates allocation rates based on predicted demands. 

Column 15, lines 65-67. Laksham does not use or suggest the use of a bitrate spike 

i t ' \ 
or a bitrate histogram in any of its prediction modeling, 

I ' ! 

The addition of Ito does not cure the deficiencies of Lakshman. (to does not 

i : 

disclose bitrate histograms. Rather, Ito's video data index includes instructions for 

i : 
i 

i 

i 

14 
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!■ 

i 

how to extract certain frames of video datai to achieve one of several different bitrates 

depending on the network load. Irji other words, if tfte network load won't permit the 

I ' 

transmission full 1.5 Mbps video (data, Itp's serveri degrades the video quality, as- 

i 
i 

instructed in the video data Index, by selecting some frames and dropping others. 

The addition of Humplenilan does not cure the deficiencies of Ito and 
Lakshman. Humpleman merely discloses a home network system that provides 

i 

browser-based command and control. Nothing in Humpleman suggests the claimed- 

:! ! 

bitrate histogram. Furthermore,! nothing in Humpleman suggests modifying a 

■ i I 

bandwidth allocation in anticipation of a bitrate spike indicated within a bitrate 

i 

histogram. I r 

Because the cited references fail to disclose the limitations of claim 1, they 

cannot anticipate claim 1. Anticipation under setotion 102 is proper only if the 

■ 1 i 

reference shows exactly what is claimed. Titanium Metals Corp. v. Banner . 778 F.2d 

I ! 

775, 780, 227 USPQ 773, 777 (Fed. Cir. 1985); MPEP § 213101. The applicant 

,i | 

respectfully submits that claim 1:| is patentably distinct over the cited references. 

: ! ; ' 

•i ' 1 

Claims 2-7 depend directly or indirectly from claim 1 and are thus believed to be 

i • 

patentably distinct for at least the same reasons. 



Accordingly, the applicant 
distinct over the cited references 



respectfully submits that claim 1 is patentably 
Claims 2-7 depend directly or indirectly from claim 



1 and are thus believed to be patentably distinct for at least the same reasons. 

i 
i 

Claim 8 recites dynamically; adjusting said first amount of bandwidth based on 

a previously-generated template of bitrate data as a function of time. As explained 

• • i 

i 

above, Lakshman does not disclose a template of bitrate as a function of time. 
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Furthermore, Lakshman does nek disclose a previously-generated histogram of 
bitrate as a function of time associated with a previously-encoded multimedia 
program. 

Claim 12 depends from claim 8 and requires the further step of "dynamically 
adjusting said first amount of bandwidth based on a histogram of bitrate data 
indicating changes in bitrate requfremenfe of a multimedia program requested by a 
second multimedia node." Lakshman does not disclose changing a bandwidth* 
allocation of a first multimedia node: based on a bitrate histogram of a second 
multimedia node. Even if Lakshman's prediction could be construed to be a template 
of bitrate data with respect to time, which it cannot, Lakshman does not make 
bandwidth allocation changes based on Tartrate, requirements of a multimedia 
program requested by a second multimedia node." 

respectfully submits that claims 8 and 12 are 
patentably distinct over Lakshman, Claims 9-17 depend directly or indirectly from 
claim 8 and are thus believed to be patentably distinct for at least the same reasons. 
Claims 18-29 include similar limitations to those found in claims 1-17 and are likewise 
believed to be patentably distinct ; 

Claim 29 further recites "identifying a second bitrate histogram associated with 

a second multimedia program to be transmitted to a second multimedia node, the 

i 

second bitrate histogram indicating a future spike in bandwidth requirements for the 



Accordingly, the applicant 



second multimedia program" and 
multimedia program just prior to 
the second multimedia program 



"throttling back the bandwidth allocated to the first 
encountering the bandwidth spike associated with 
at a time sufficient to fill a buffer of the first 
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multimedia node." The applicant respectfully submits that none of the cited 
references disclose throttling back bandwidth of a first multimedia program based on 



1022/024 



irements of a second multimedia program 

econd multimedia program. 

prising: 

bitrate as a function of time for an entire 
n thereof to a multimedia node; 



an anticipated spike in the bandwidth reqji 

' ! i 
■ ! ; 

as indicated by a bitrate histogram for the 

; I , * 

I I I 

New claim 30 recites a method coi 

generating a histogram ;of j 
media program before a transmissi 

' i ' 

allocating a first amount jfcf network bandwidth for transmitting the 
media program to the multimedial node, the first amount being a subset of 
available network bandwidth jto the] multimedia node; 

identifying, during j jtrarisp;ission of the multimedia program, an 
upcoming bitrate spike within the titrate histogram for the multimedia program, 
the bitrate spike temporarily [rejejuiring more than the available network 
bandwidth for transmission jcf the nj ultimedia program; 

temporarily increasing thkl bandwidth allocation for the multimedia 
node from the first amount (to a &?cond amount in anticipation of the future 

'^ate histogram, the temporarily increased 
£ it to fill a buffer at the multimedia node to 
:inedia node during the future bitrate spike. 



bitrate spike indicated in; the bm 
bandwidth allocation being; sufficie 
avoid a buffer underrun at the mult 



bitrate as a function of time for ah 
thereof to a multimedia node. As hoted 



Unlike the claimed invention, Lakshman does not generate a histogram of 

; m 
entire! 



multimedia program before a transmission 

ii 

hbove, Lakshman relates to video that has 



i 



fill a buffer at the multimedia node to avo 
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not yet been encoded, such as in a vide > conference. CoL 9, lines 64-67. Hence, 

Lakshman cannot generate a histogram Tpr an entire multimedia program before it is 

| i i 

transmitted to the multimedia nodeJ 

' I ! 

Moreover, Lakshman does j not temporarily increase a program's bandwidth 



allocation in anticipation of the future bttrrate spike indicated in a bitrate histogram to 



d a buffer underrun during the future bitrate 
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spike. At best, Lakshman only predicts! 

; I 



then adjusts (505) the current rate 



basi 



Lakshman's encoder adjusts the encoding rate clearly shows that the media program 



r • 

has not yet been encoded, contrary to the 



Also, adjusting the encoder 

j 

bandwidth exists to transmit the 



media 



claimed process of temporarily in lanipiiilating the' bandwidth allocation based on 

foreknowledge of upcoming bitrate 

j 

with perfect quality, in such cases, 



the claimed invention preserves quality. 



In view of the foregoing, the 



(2)023/024 



501) the heed for rate allocation forfeiture 
frames and provides (502) the predicated rate to a j network. The network allocates 

(504) bandwidth in response to ithe request and ^advises (504) the source * of an 

| i i 

explicit rate based on the actual; available bandwidth. The encoder at the source 



on the advised explicit rate. The fact that 



claimed invention. 



(aiidjtiereby reducing quality) where insufficient 



program iis completely different from the 



I 

spiked so that, the media program is transmitted 



Lakshman always results in quality loss, whereas 



applicant respectfully submits that claims 1-31 , as 



amended, are patentably distinct lojverth^ cited references, alone or in combination. 
A Notice of Allowance is respefrfulty requested. : If any issues remain after this 

! i I 

i ' i 

response, the Examiner is invited to jejontact the undersigned at the telephone 
number provided below. 
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STOEL RIVES LLP ! 

One Utah Center Suite 1 100 j 

201 S Main Street j 

Salt Lake City, UT 841 1 1 -4904 ! 

Telephone: (801)328-3131 ! 

Facsimile: (801)578-6999 j 
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Respectfully submitted, 
Digeo, Inc. 




. Chiristensen 
(Registration No. 43.648 



10 



©024/024 



>ry 



-1/1 ■ DNIS:8729306 ' CSiD:801 578 6999 ' DURATION (mm-ss):06-16 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




[NES OR MARKS ON ORIGINAL DOCUMENT 



